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Abstract 


This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients 
with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call 
Home. It can be useful to know the appropriate DOTS server for a given location in order to 
engage mitigation actions. This is true even in cases where the DOTS client cannot localize the 
attack: cases where it only knows that some resources are under attack and that help is needed. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8973. 
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reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture in which a DOTS client 
can inform a DOTS server that the network is under a potential attack and that appropriate 
mitigation actions are required. Indeed, because the lack of acommon method to coordinate a 
real-time response among involved actors and network domains inhibits the effectiveness of 
DDoS attack mitigation, the DOTS signal channel protocol [RFC8782] is meant to carry requests 
for DDoS attack mitigation. With this approach, DOTS can reduce the impact of an attack and 
lead to more efficient defensive actions in various deployment scenarios, such as those discussed 
in [DOTS-USE-CASES]. Moreover, DOTS clients can instruct a DOTS server to install named 
filtering rules by means of the DOTS data channel protocol [RFC8783]. 


The basic high-level DOTS architecture is illustrated in Figure 1. 


+----------- + +------------- + 
| Mitigator | ~x..n...r.<.~ | DOTS Server | 
+----------- + +------ +------ + 

| 

| 

| 
+--------------- + +------ +------ + 
| Attack Target | ~~x~x~x~x~ | DOTS Client | 
4--------------- + +------------- + 


Figure 1: Basic DOTS Architecture 


[RFC8811] specifies that the DOTS client may be provided with a list of DOTS servers, each 
associated with one or more IP addresses. These addresses may or may not be of the same 
address family. The DOTS client establishes one or more DOTS sessions by connecting to the 
provided DOTS server addresses. 


This document specifies methods for DOTS clients to discover their DOTS server(s). The rationale 
for specifying multiple discovery mechanisms is discussed in Section 3. 
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The discovery methods can also be used by a DOTS server to locate a DOTS client in the context of 
DOTS signal channel Call Home [DOTS-SIG-CALL-HOME]. The basic high-level DOTS Call Home 
architecture is illustrated in Figure 2. 


+--------------- + +------------- + 
| Alert | www | Call Home | 
| | | DOTS Client | 
+--------------- + +------ +------ + 

| 

| 

| 
+--------------- + +------ +------ + 
| Attack | wenn | Call Home | 
l Source(s) l | DOTS Server | 
+--------------- + +------------- + 


Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture 


A DOTS agent may be used to establish base DOTS channels, DOTS Call Home, or both. This 
specification accommodates all these deployment cases. 


Considerations for the selection of DOTS server(s) by multihomed DOTS clients are out of this 
document's scope; readers should refer to [DOTS-MULTIHOMING] for more details. 


This document assumes that security credentials to authenticate DOTS server(s) are pre- 
provisioned to a DOTS client using a mechanism such as (but not limited to) those discussed in 
[RFC8572] or [BTSRP-KEYINFR]. DOTS clients use those credentials for authentication purposes 
following the rules documented in [RFC8782]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


The reader should be familiar with the terms defined in [RFC3958]. 


This document makes use of the following terms: 


DHCP: refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 


DOTS client: refers to a DOTS-aware software module responsible for requesting attack 
response coordination with other DOTS-aware elements. 


DOTS server: is a DOTS-aware software module handling and responding to messages from 
DOTS clients. The DOTS server enables mitigation on behalf of the DOTS client, if requested, 
by communicating the DOTS client's request to the mitigator and returning selected mitigator 
feedback to the requesting DOTS client. 
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Call Home DOTS client or server: refers toa DOTS client or server deployed in a Call Home 
scenario (Figure 2). 


DOTS agent: is any DOTS-aware software module capable of participating in a DOTS channel. 


Peer DOTS agent: refers to the peer DOTS server (base DOTS operation) or to a peer Call Home 
DOTS client (for DOTS signal channel Call Home). 


3. Why Multiple Discovery Mechanisms? 


Analysis of the various use cases sketched in [DOTS-USE-CASES] reveals that it is unlikely that 
one single discovery method can be suitable for all the sample deployments. Concretely: 


e Many of the use cases discussed in [DOTS-USE-CASES] do involve Customer Premises 
Equipment (CPE). Multiple CPEs connected to distinct network providers may even be 
considered. It is intuitive to leverage existing mechanisms, such as discovery using service 
resolution or DHCP, to provision the CPE acting as a DOTS client with the DOTS server(s). 


e Resolving a DOTS server domain name offered by an upstream transit provider provisioned 
to a DOTS client into IP address(es) requires the use of the appropriate DNS resolvers; 
otherwise, resolving those names will fail. The use of protocols, such as DHCP, does allow 
associating provisioned DOTS server domain names with a list of DNS servers to be used for 
name resolution. Furthermore, DHCP allows for directly providing IP addresses, therefore, 
avoiding the need for extra lookup delays. 


e Some of the use cases may allow DOTS clients to have direct communications with upstream 
DOTS servers, that is, no DOTS gateway is involved. Leveraging existing protocol behaviors 
that do not require specific features on the node embedding the DOTS client may ease DOTS 
deployment. Typically, the use of Straightforward-Naming Authority Pointer (S-NAPTR) 
lookups [RFC3958] allows the DOTS server administrators to provision the preferred DOTS 
transport protocol between the DOTS client and the DOTS server and allows the DOTS client 
to discover this preference. 


° The upstream network provider is not the DDoS mitigation provider for some of these use 
cases. It is safe to assume that, for such deployments, the DOTS server(s) domain name is 
provided during the service subscription (i.e., manual/local configuration). 


e Multiple DOTS clients may be enabled within a network (e.g., an enterprise network). 
Dynamic discovery needs to be deterministic from an operational standpoint. 


e Some of the use cases may involve a DOTS gateway that is responsible for selecting the 
appropriate DOTS server(s) to relay requests received from DOTS clients. 


Consequently, this document describes a unified discovery logic (Section 4) that involves the 
following mechanisms: 


e dynamic discovery using DHCP (Section 5) 
e a resolution mechanism based on S-NAPTR resource records in the DNS (Section 6) 
e DNS Service Discovery (Section 7) 
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4. DOTS Discovery Procedure 


Operators will need a consistent set of ways in which DOTS clients can discover this information 
and a consistent priority among these options. If some devices prefer manual configuration over 
dynamic discovery while others prefer dynamic discovery over manual configuration, the result 
will be a process where the operator must find devices that are using the wrong DOTS server(s), 
determine how to ensure the devices are configured properly, and then reconfigure the device 
through the preferred method. 


All DOTS clients MUST support at least one of the three mechanisms below to determine a DOTS 
server list. All DOTS clients SHOULD implement all three, or as many as are practical for any 
specific device, of the following ways to discover DOTS servers in order to facilitate the 
deployment of DOTS in large-scale environments. For example, a CPE will support the first two 
mechanisms, a host within a LAN will support the last two mechanisms, or an application server 
will support a local configuration. More examples are discussed in Section 3. DOTS clients will 
prefer information received from the discovery methods in the order listed below. 


1. Explicit Configuration: 


Local/Manual Configuration: A DOTS client will learn the DOTS server(s) by means of local 
or manual DOTS configuration (i.e., DOTS servers configured at the system level). 
Configuration discovered from a DOTS client application is considered a local 
configuration. 


An implementation may give the user an opportunity (e.g., by means of configuration file 
options or menu items) to specify DOTS server(s) for each address family. These may be 
specified either as a list of IP addresses or the DNS name of a DOTS server. When only 
DOTS server IP addresses are configured, a reference identifier must also be configured 
for authentication purposes. 


Automatic Configuration (e.g., DHCP): The DOTS client attempts to discover DOTS server(s) 
names and/or addresses from DHCP, as described in Section 5. 


2. Service Resolution: The DOTS client attempts to discover DOTS server name(s) using service 
resolution, as specified in Section 6. 

3. DNS-SD: DNS-based Service Discovery. The DOTS client attempts to discover DOTS server 
name(s) using DNS service discovery, as specified in Section 7. 


Some of these mechanisms imply the use of DNS to resolve the IP address(es) of the DOTS server, 
while others imply an IP address of the relevant DOTS server is obtained directly. 
Implementation options may vary on a per-device basis, as some devices may not have DNS 
capabilities and/or suitable DNS configuration. 
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On hosts with more than one interface or address family (IPv4/IPv6), the DOTS server discovery 
procedure has to be performed for each interface-/address-family combination. A DOTS client 
may choose to perform the discovery procedure only for a desired interface/address 
combination if the client does not wish to discover a DOTS server for all interface-/address-family 
combinations. 


This procedure is also followed by a Call Home DOTS server to discover its Call Home DOTS client 
in the context of [DOTS-SIG-CALL-HOME]. 


The discovery method is performed upon the bootstrapping of a DOTS agent and is reiterated by 
the DOTS agent upon the following events: 


e expiry of a validity timer (e.g., DHCP lease, DHCP information refresh time, or DNS TTL) 
associated with a discovered DOTS agent 


e expiry of the certificate of a peer DOTS agent currently in use 
e attachment to a new network 


5. DHCP Options for DOTS Agent Discovery 


As reported in Section 1.7.2 of [RFC6125]: 


Some certification authorities issue server certificates based on IP addresses, but 
preliminary evidence indicates that such certificates are a very small percentage (less 
than 1%) of issued certificates. 


In order to allow for PKIX-based authentication between a DOTS client and server while 
accommodating the current best practices for issuing certificates, this document allows DOTS 
agents to retrieve the names of their peer DOTS agents. These names can be used for two 
purposes: (1) to retrieve the list of IP addresses of a peer DOTS agent or (2) to be presented as a 
reference identifier for authentication purposes. 


Defining the option to include a list of IP addresses would avoid depending on an underlying 
name resolution, but that design requires also supplying a name for PKIX-based authentication 
purposes. 


Given that DOTS gateways can be involved in a DOTS session, a peer DOTS agent can be 
reachable using a link-local address. Such addresses can also be discovered using the options 
defined in Section 5.1. 


The list of the IP addresses returned by DHCP servers is typically used to feed the DOTS server 
selection procedure, including when DOTS agents are provided with primary and backup IP 
addresses of their peer DOTS agents. An example of the DOTS server selection procedure is 
specified in Section 4.3 of [RFC8782]. 
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The design assumes that the same peer DOTS agent is used for establishing both signal and data 
channels. For more customized configurations (e.g., transport-specific configuration and distinct 
DOTS servers for the signal and data channels), an operator can supply only a DOTS reference 
identifier that will be then passed to the procedure described in Section 6. 


The design allows terminating the base DOTS channels and DOTS Call Home on the same or 
distinct peer DOTS agents. If distinct peer DOTS agents are deployed, the DHCP option can return, 
for example, a list of IP addresses to a requesting DOTS agent. This list includes the IP address to 
be used for the base DOTS channels and the IP address for the DOTS Call Home. The DOTS client 
(or Call Home DOTS server) will then use the address selection procedure specified in Section 4.3 
of [RFC8782] to identify the IP address of the peer DOTS server (or Call Home DOTS client). 


For example, let's consider that the DOTS server is reachable at 2001:db8:122:300::1, while the 
Call Home DOTS client is reachable at 2001:db8:122:300::2. The DHCP server will then return one 
DOTS reference identifier and a list that includes both 2001:db8:122:300::1 and 
2001:db8:122:300::2 to a requesting DHCP client. That list is passed to the DOTS client (or Call 
Home DOTS server), which will try to establish connections to the addresses of that list and 
destination port number 4646 (or the Call Home port number). As a result, the DOTS client (or 
Call Home DOTS server) will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server 
(or Call Home DOTS client). 


5.1. DHCPv6 DOTS Options 


5.1.1. Format of DOTS Reference Identifier Option 


The DHCPv6 DOTS Reference Identifier option is used to configure the name of the DOTS server 
(or the name of the Call Home DOTS client). The format of this option is shown in Figure 3. 


@12345678901234567898123456789801 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_V6_DOTS_RI | Option-length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 
l dots-agent-name (FQDN) l 
| | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 3: DHCPv6 DOTS Reference Identifier Option 


The fields of the option shown in Figure 3 are as follows: 


Option-code: OPTION_V6_DOTS_RI (141, see Section 9.2). 

Option-length: Length of the dots-agent-name field in octets. 

dots-agent-name: A fully qualified domain name of the peer DOTS agent. This field is formatted 
as specified in Section 10 of [RFC8415]. 


An example of the dots-agent-name encoding is shown in Figure 4. This example conveys the 
FQDN "dots.example.com", and the resulting Option-length field is 18. 
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+------ +------ +------ +------ +------ +------ +------ +------ +------ + 
| 0x04 | d | o (| ~ (|| s | 0x07 | e | X a | 
+------ +------ +------ +------ +------ +------ +------ +------ +------ + 
| m | p | | e | @x@3 | @ | o (| m | @x@e | 
+------ +------ +------ +------ +------ +------ +------ +------ +------ + 


Figure 4: An Example of the dots-agent-name Encoding 


5.1.2. Format of DOTS Address Option 


The DHCPv6 DOTS Address option can be used to configure a list of IPv6 addresses of a DOTS 
server (or a Call Home DOTS client). The format of this option is shown in Figure 5. 


OMI 2a 3 ANSTO STOO M2 e374 56/1659 sO TA 8 oO ral 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

OPTION_V6_DOTS_ADDRESS l Option-length l 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| 
DOTS ipv6-address | 


+ 
| 
+ 
| 
| 
| 
| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 
| 
| 
| 
+ 
| 
+ 


| 
DOTS ipv6-address | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


E E a re yehy 
Figure 5: DHCPv6 DOTS Address Option 


The fields of the option shown in Figure 5 are as follows: 


Option-code: OPTION_V6_DOTS_ADDRESS (142, see Section 9.2). 

Option-length: Length of the DOTS ipv6-address fields in octets. This MUST be a multiple of 16. 

DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] of the peer DOTS agent to 
be used by a DOTS agent for establishing a DOTS session. The addresses are listed in the order 
of preference for use by the DOTS agent. 


Note that IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) may be included in this 
option when there is no DHCPv4 server able to advertise the DHCPv4 DOTS options (Section 5.2) 
and when only IPv4 connectivity is possible to the peer DOTS agent. 
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5.1.3. DHCPv6 Client Behavior 


DHCP clients MAY request options OPTION_V6_DOTS_RI and OPTION_V6_DOTS_ADDRESS, as 
defined in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. As a convenience to 
the reader, it is mentioned here that the DHCP client includes the requested option codes in the 
Option Request option. 


If the DHCP client receives more than one instance of option OPTION_V6_DOTS_RI (or 
OPTION_V6_DOTS_ADDRESS), it MUST use only the first instance of that option. 


The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] 
conveyed in OPTION_V6_DOTS_ADDRESS. 


If the DHCP client receives and validates both OPTION_V6_DOTS RI and 
OPTION_V6_DOTS_ADDRESS, the content of OPTION _V6_DOTS_RI is used as the reference 
identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included 
in OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In other words, the name 
conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to an underlying resolution library in the 
presence of a valid OPTION_V6_DOTS_ADDRESS in a response. 


If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI contains more 
than one name, the DHCP client MUST use only the first name. Once the name is validated 
(Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name 
is also used as a reference identifier for authentication purposes. 


If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the address(es) included in 
OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In addition, these addresses 
can be used as identifiers for authentication. 


5.2. DHCPv4 DOTS Options 


5.2.1. Format of DOTS Reference Identifier Option 


The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to configure a name of the peer 
DOTS agent. The format of this option is illustrated in Figure 6. 


Code Length Peer DOTS agent name 


Figure 6: DHCPv4 DOTS Reference Identifier Option 
The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. 


The fields of the option shown in Figure 6 are as follows: 
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Code: OPTION_V4_DOTS_RI (147, see Section 9.3). 

Length: Includes the length of the "Peer DOTS agent name" field in octets. 

Peer DOTS agent name: The domain name of the peer DOTS agent. This field is formatted as 
specified in Section 10 of [RFC8415]. 


5.2.2. Format of DOTS Address Option 


The DHCPv4 DOTS Address option can be used to configure a list of IPv4 addresses of a peer 
DOTS agent. The format of this option is illustrated in Figure 7. 


@1234567898012345 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Code=148 | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 

| 

+ 

| | 
| DOTS IPv4 Address | 
| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 
| 

| 

| 

+ 


| | 
DOTS IPv4 Address | | 
| optional 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l 


e eye eee ay --- 
Figure 7: DHCPv4 DOTS Address Option 


The fields of the option shown in Figure 7 are as follows: 


Code: OPTION_V4_DOTS_ADDRESS (148, see Section 9.3). 

Length: Set to 4*N, where N is the number of IPv4 addresses included in the option. 

DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the peer DOTS agent to be used 
by a DOTS agent. The addresses are listed in the order of preference for use by the DOTS 
agent. 


OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, the mechanism 
specified in [RFC3396] MUST be used if OPTION_V4_DOTS_ADDRESS exceeds the maximum 
DHCPv4 option size of 255 octets. 

5.2.3. DHCPv4 Client Behavior 

To discover a peer DOTS agent, the DHCPV4 client MUST include both OPTION_V4_DOTS_RI and 
OPTION_V4_DOTS_ADDRESS in a Parameter Request List option [RFC2132]. 


If the DHCP client receives more than one instance of OPTION_V4_DOTS_RI option, it MUST use 
only the first instance of that option. 


The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] 
conveyed in OPTION_V4_DOTS_ADDRESS. 
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If the DHCP client receives and validates both OPTION_V4_DOTS RI and 
OPTION_V4_DOTS_ADDRESS, the content of OPTION _V4_DOTS_RI is used as the reference 
identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included 
in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In other words, the name 
conveyed in OPTION_V4_DOTS_RI MUST NOT be passed to an underlying resolution library in the 
presence of valid OPTION_V4_DOTS_ADDRESS in a response. 


If the DHCP client receives OPTION_V4_DOTS_RI only, but OPTION_V4_DOTS_RI option contains 
more than one name, as distinguished by the presence of multiple root labels, the DHCP client 
MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is 
passed to a name resolution library. Moreover, that name is also used as a reference identifier 
for authentication purposes. 


If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the address(es) included in 
OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS server. In addition, these addresses 
can be used as identifiers for authentication. 


6. Discovery Using Service Resolution 


This mechanism is performed in two steps: 


1. A DNS domain name is retrieved for each combination of interface and address family. A 
DOTS agent has to determine the domain in which it is located relying on dynamic means, 
such as DHCP (Section 5). Implementations may allow the user to specify a default name that 
is used if no specific name has been configured. 


2. Retrieved DNS domain names are then used for S-NAPTR lookups [RFC3958]. Further DNS 
lookups may be necessary to determine the peer DOTS agent IP address(es). 


Once the DOTS agent has retrieved its DNS domain or discovered the peer DOTS agent name that 
needs to be resolved, an S-NAPTR lookup with the appropriate application service and the 
desired protocol tag is made to obtain information necessary to connect to the authoritative peer 
DOTS agent within the given domain. 


This specification defines "DOTS" and "DOTS-CALL-HOME" as application service tags (Sections 
9.4.1 and 9.4.2). It also defines "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and 
"data.tcp" (Section 9.4.5) as application protocol tags. An example is provided in Figure 8. 


In the example below, for domain "example.net", the resolution algorithm will result in IP 
address, port, tag, and protocol tuples listed in Table 1. 


Boucadair & Reddy.K Standards Track Page 12 


RFC 8973 DOTS Server/Call Home Client Discovery 


example.net. 


IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 
IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 


IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 


signal.example.net. 


IN NAPTR 100 18 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. 
IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. 


data.example.net. 


IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. 


IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net. 


_dots-signal._udp.example.net. 
IN SRV © © 5000 a.example.net. 


_dots-signal._tcp.example.net. 
IN SRV © © 5001 a.example.net. 


_dots-data._tcp.example.net. 


IN SRV © © 5002 a.example.net. 


a.example.net. 
IN AAAA 2001:db8::1 


b.example.net. 
IN AAAA 2001:db8: :2 


Figure 8: Example of Discovery of DOTS Servers Using Service Resolution 


Order Protocol IP address 


1 UDP 
2 TCP 
3 TCE 
4 TCP 


2001:db8::1 


2001:db8::1 


2001:db8::1 


2001:db8::2 


Table 1: Resolution Results 


Port 


5000 


5001 


5002 


443 


Tag 
Signal 
Signal 
Data 


Data 


January 2021 


An example is provided in Figure 9 for the Call Home case. In this example, the resolution 
algorithm will result in IP address, port, and protocol tuples listed in Table 2 for domain 


"example.net". 


Boucadair & Reddy.K 


Standards Track 


Page 13 


RFC 8973 DOTS Server/Call Home Client Discovery January 2021 


example.net. 
IN NAPTR 100 18 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. 
IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. 


signal.example.net. 

IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" 
_dots-call-home._udp.example.net. 

IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" 
_dots-call-home._tcp.example.net. 


_dots-call-home._udp.example.net. 
IN SRV © © 6000 b.example.net. 


_dots-call-home._tcp.example.net. 
IN SRV @ © 6001 b.example.net. 


b.example.net. 
IN AAAA 2001 :db8::2 


Figure 9: Example of Discovery of DOTS Call Home Client Using Service Resolution 


Order Protocol IP address Port 
1 UDP 2001:db8::2 6000 


2 TCP 2001:db8::2 6001 
Table 2: Resolution Results (Call Home) 


Note that customized port numbers are used for the DOTS signal channel, DOTS data channel, 
and DOTS signal channel Call Home in the examples shown in Figures 8 and 9 for illustration 
purposes. If default port numbers are used in a deployment, the discovery procedure will return 
4646 (DOTS signal channel) and 443 (DOTS data channel) as DOTS service port numbers. 


If no DOTS-specific S-NAPTR records can be retrieved, the discovery procedure fails for this 
domain name (and the corresponding interface and IP protocol version). If more domain names 
are known, the discovery procedure MAY perform the corresponding S-NAPTR lookups 
immediately. However, before retrying a lookup that has failed, a DOTS client MUST wait a time 
period that is appropriate for the encountered error (e.g., NXDOMAIN, timeout, etc.). 


7. DNS Service Discovery 


DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic solutions for discovering 
services. DNS-SD defines a set of naming rules for certain DNS record types that they use for 
advertising and discovering services. 
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Section 4.1 of [RFC6763] specifies that a service instance name in DNS-SD has the following 
structure: 


<Instance> . <Service> . <Domain> 


The <Domain> portion specifies the DNS subdomain where the service instance is registered. It is 
a conventional domain name, such as "example.com". 


The <Service> portion of the DOTS service instance name MUST be "_dots-signal._udp", "_dots- 


signal._tcp", "_dots-data._tcp", "_dots-call-home._udp", or "_dots-call-home._tcp". 
This document does not define any keys; the TXT record of a DNS-SD service is thus empty 
(Section 6 of [RFC6763]). 


Figure 10 depicts an excerpt of the DNS zone configuration file listing record examples to 
discover two DOTS signal channel servers. In this example, only UDP is supported as transport 
for the establishment of the DOTS signal channel. 


_dots-signal._udp.example.net. PTR a._dots-signal._udp.example.net. 
_dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net. 
a._dots-signal._udp.example.net. SRV © © 4646 a.example.net. 
b._dots-signal._udp.example.net. SRV © © 4646 b.example.net. 
a._dots-signal._udp.example.net. TXT "" 
b._dots-signal._udp.example.net. TXT "" 


Figure 10: An Example of DNS-SD Records for the UDP DOTS Signal Channel Involving Two Servers 
with the Same Priority 


8. Security Considerations 


DOTS-related security considerations are discussed in Section 5 of [RFC8811]. As a reminder, 
DOTS agents must authenticate each other using (D)TLS before a DOTS session is considered 
valid according to the [RFC8782]. 


An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery 
mechanism with a lower priority. The security implications of such attack are those inherent to 
the fallback discovery mechanism discussed in the following subsections. 


The results of the discovery procedure are a function of the interface/address family. Contacting 
a discovered DOTS server via an interface to which it is not bound may exacerbate the delay 
required to establish a DOTS channel. Moreover, such behavior may reveal that a DOTS service is 
enabled by a DOTS client domain and exposes the identity of the DOTS service provider (which 
can be inferred from the name and the destination IP address) to external networks. 


Security considerations related to how security credentials to authenticate DOTS server(s) are 
provisioned to a DOTS client are those inherent to the mechanism used for that purpose (for 
example, see [RFC8572]). 
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8.1. DHCP 


The security considerations in [RFC2131] and [RFC8415] are to be considered. In particular, 
issues related to rogue DHCP servers and means to mitigate many of these attacks are discussed 
in Section 22 of [RFC8415]. 


An attacker can get a domain name, get a domain-validated public certificate from a certification 
authority (CA), and host a DOTS agent. An active attacker can then spoof DHCP responses to 
include the attacker's DOTS agent. Such an attacker can also launch other attacks, as discussed in 
Section 22 of [RFC8415]. In addition to the mitigations listed in Section 22 of [RFC8415], a DOTS 
agent may be preconfigured with a list of trusted DOTS domain names. If such a list is 
preconfigured, a DOTS agent will accept a DHCP-discovered name if it matches a name in that 
list. Also, the DOTS agent has to check that the "DNS-ID" identifier type within subjectAltName in 
the server certificate matches a preconfigured name. If the DOTS agent is instructed to trust 
subdomains of the names in that list as well (e.g., "**example.com"), a DOTS agent will accept a 
DHCP-discovered name that matches a name in the preconfigured list (e.g., "dots-1.example.com" 
or "dots-2.example.com"). 


Relying on an underlying resolution library to resolve a supplied reference identifier has similar 
security issues as those discussed in Section 8.2 (e.g., an active attacker may modify DNS 
messages used to resolve the supplied reference identifier and point the client to an attacker 
server). 


Supplying both an IP address and the reference identifier makes it easier to use a mis-issued 
certificate. 


8.2. Service Resolution 


The primary attack against the methods described in Section 6 is one that would lead to 
impersonation of a peer DOTS agent. An attacker could attempt to compromise the S-NAPTR 
resolution. 


The DOTS client (or a Call Home DOTS server) constructs one reference identifier for the DOTS 
server (or a Call Home DOTS client) based on the domain name that is used for S-NAPTR lookup: 
DNS-ID. If the reference identifier is found (as described in Section 6 of [RFC6125]) in the PKIX 
certificate's subjectAltName extension, the DOTS client should accept the certificate for the 
server. 


DNS Security Extensions (DNSSEC) [RFC4033] uses cryptographic keys and digital signatures to 
provide authentication of DNS data. The information that is retrieved from the S-NAPTR lookup 
and that is validated using DNSSEC is thereby proved to be the authoritative data. 
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8.3. DNS Service Discovery 


Since DNS-SD is a specification for how to name and use records in the existing DNS system, it 
has no specific additional security requirements over and above those that already apply to DNS 
queries and DNS updates. For DNS queries, DNSSEC SHOULD be used where the authenticity of 
information is important. For DNS updates, secure updates [RFC2136] [RFC3007] SHOULD 
generally be used to control which clients have permission to update DNS records. 


Note that means such as DNS over TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC8484] can 
be used to prevent eavesdroppers from accessing DNS messages. 


9. IANA Considerations 


9.1. Service Name and Transport Protocol Port Number Registry 


IANA has allocated the following service names from the registry available at: <https:// 
www.iana.org/assignments/service-names-port-numbers/>. 


Service Name: 
Port Number: 


Transport Protocol(s): 


Description: 


Assignee: 
Contact: 
Reference: 


Service Name: 


Transport Protocol(s): 


Description: 


Assignee: 
Contact: 
Reference: 


dots-data 

N/A 

TCP 

DOTS Data Channel Protocol. The service name is used to construct the 
SRV service name "_dots-data._tcp" for discovering DOTS servers used 
to establish DOTS data channel. 

IESG: iesg@ietf.org 

IETF Chair: chair@ietf.org 

[RFC8973] 


dots-call-home 

TCP/UDP 

DOTS Signal Channel Call Home Protocol. The service name is used to 
construct the SRV service names "_dots-call-home._udp" and "_dots- 
call-home._tcp" for discovering Call Home DOTS clients used to 
establish DOTS signal channel Call Home. 

IESG: iesg@ietf.org 

IETF Chair: chair@ietf.org 

[RFC8973] 


IANA has updated the following entry from the registry available at: <https://www.iana.org/ 
assignments/service-names-port-numbers/>. 


Port Number: 


Transport Protocol(s): 
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Description: DOTS Signal Channel Protocol. The service name is used to construct 
the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for 
discovering DOTS servers used to establish DOTS signal channel. 


Assignee: IESG: iesg@ietf.org 
Contact: IETF Chair: chair@ietf.org 
Reference: [RFC8782][RFC8973] 


9.2. DHCPv6 Options 


IANA has assigned the following new DHCPv6 Option Codes in the registry maintained in 
<https://www.iana.org/assignments/dhcpv6-parameters/>. 


Value Description Client ORO Singleton Option 
141 OPTION_V6_DOTS_RI Yes Yes 
142 OPTION_V6_DOTS_ADDRESS Yes Yes 


Table 3: DHCPv6 Options 


9.3. DHCPv4 Options 


IANA has assigned the following new DHCPv4 Option Codes in the registry maintained in 
<https://www.iana.org/assignments/bootp-dhcp-parameters/>. 


Name Tag Data Length Meaning Reference 
OPTION_V4_DOTS RI 147 N The name of the peer [RFC8973] 
DOTS agent. 


OPTION_V4_DOTS_ADDRESS 148 N (the minimal N/4IPv4 addresses of [RFC8973] 
length is 4) peer DOTS agent(s). 


Table 4: DHCPv4 Options 


9.4. Application Service & Application Protocol Tags 


IANA has made the following allocations from the registries available at <https://www.iana.org/ 
assignments/s-naptr-parameters/> for application service tags and application protocol tags. 


9.4.1. DOTS Application Service Tag Registration 


Application Service Tag: DOTS 
Intended Usage: See Section 6 
Security Considerations: See Section 8 
Interoperability Considerations: None 
Relevant Publications: RFC 8973 
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9.4.2. DOTS Call Home Application Service Tag Registration 


Application Service Tag: 
Intended Usage: 
Security Considerations: 


Interoperability Considerations: 


Relevant Publications: 


DOTS-CALL-HOME 
See Section 6 

See Section 8 
None 

RFC 8973 


9.4.3. signal.udp Application Protocol Tag Registration 


Application Protocol Tag: 
Intended Usage: 
Security Considerations: 


Interoperability Considerations: 


Relevant Publications: 


signal.udp 
See Section 6 
See Section 8 
None 

RFC 8973 


9.4.4. signal.tcp Application Protocol Tag Registration 


Application Protocol Tag: 
Intended Usage: 
Security Considerations: 


Interoperability Considerations: 


Relevant Publications: 


signal.tcp 
See Section 6 
See Section 8 
None 

RFC 8973 


9.4.5. data.tcp Application Protocol Tag Registration 


Application Protocol Tag: 
Intended Usage: 
Security Considerations: 


Interoperability Considerations: 


Relevant Publications: 


10. References 


10.1. Normative References 


data.tcp 

See Section 6 
See Section 8 
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